Skip to content

OpenBSD Wireguard implementation - #3750

Merged
ipspace merged 2 commits into
ipspace:devfrom
snuffy22:openbsd-wg
Aug 9, 2026
Merged

OpenBSD Wireguard implementation#3750
ipspace merged 2 commits into
ipspace:devfrom
snuffy22:openbsd-wg

Conversation

@snuffy22

@snuffy22 snuffy22 commented Aug 8, 2026 •
edited
Loading

Copy link
Copy Markdown
Contributor

This is more open for comment than ready for commit.

Three issues:

  1. OpenBSD does not create IPv6 LLA addresses on WG interfaces because they are technically multipoint
  2. Wireguard IPv6 test does not set prefix length for loopback (so fails for OpenBSD which only does /128)
  3. Wireguard module does not support selecting only IPv4 or IPv6

One other question, is there a reason why we might do tunnel setup after our routing protocols like OSPF?
If tunnels happened before OSPF, I could move my 'non ideal' hack out of initial and just into the Wireguard config for OpenBSD.

Wireguard Test output 
(py3-snuff) netlab@netlab:~/snuffy-netlab/tests/integration/tunnel$ netlab validate
[adj]     Check OSPFv2 adjacencies with DUT [ node(s): r2,r3 ]
[PASS]    r2: OSPFv2 neighbor 10.0.0.1 is in state Full/-
[PASS]    r3: OSPFv2 neighbor 10.0.0.1 is in state Full/-
[PASS]    Test succeeded in 0.3 seconds

[adj6]    Check OSPFv3 adjacencies with DUT [ node(s): r2,r3 ]
[PASS]    r2: OSPFv3 neighbor 10.0.0.1 is in state Full
[PASS]    r3: OSPFv3 neighbor 10.0.0.1 is in state Full
[PASS]    Test succeeded in 0.3 seconds

[pfx]     Check for DUT IPv4 loopback prefix being propagated to R2 [ node(s): r2,r3 ]
[PASS]    r2: The prefix 10.0.0.1/32 is in the OSPF topology
[PASS]    r3: The prefix 10.0.0.1/32 is in the OSPF topology
[PASS]    Test succeeded in 0.3 seconds

[pfx6]    Check for DUT IPv6 loopback prefix being propagated to R2 [ node(s): r2,r3 ]
[WAITING] Waiting for SPF to do its magic (retrying for 30 seconds)
[WAITING] Waiting for SPF to do its magic (14 seconds left)
[FAIL]    Node r2: The prefix 2001:db8:1:1::/64 is not in the OSPFv3 topology
[FAIL]    Node r3: The prefix 2001:db8:1:1::/64 is not in the OSPFv3 topology

[ping]    Check IPv4 connectivity over tunnel [ node(s): r2,r3 ]
[PASS]    r2: Ping to 10.0.0.1 succeeded
[PASS]    r3: Ping to 10.0.0.1 succeeded
[PASS]    Test succeeded in 0.3 seconds

[ping6]   Check IPv6 connectivity over tunnel [ node(s): r2,r3 ]
[PASS]    r2: Ping to ipv6 2001:db8:1:1::1 succeeded
[PASS]    r3: Ping to ipv6 2001:db8:1:1::1 succeeded
[PASS]    Test succeeded in 0.3 seconds

[mtu]     Check a full 1500-byte packet traverses the tunnel (underlay MTU 1560) [ node(s): r2,r3 ]
[PASS]    r2: Ping to 10.0.0.1 size 1500 succeeded
[PASS]    r3: Ping to 10.0.0.1 size 1500 succeeded
[PASS]    Test succeeded in 0.3 seconds

[x_ping]  Check end-to-end IPv4 connectivity [ node(s): r2 ]
[PASS]    r2: Ping to 10.0.0.3 succeeded
[PASS]    Test succeeded in 0.1 seconds

[x_ping6] Check end-to-end IPv6 connectivity [ node(s): r2 ]
[PASS]    r2: Ping to ipv6 2001:db8:1:3::1 succeeded
[PASS]    Test succeeded in 0.2 seconds

[FAIL]    16 tests completed, 2 tests failed
(py3-snuff) netlab@netlab:~/snuffy-netlab/tests/integration/tunnel$

ipspace
ipspace approved these changes Aug 9, 2026
View reviewed changes

@ipspace ipspace left a comment

Copy link
Copy Markdown
Owner

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

A minor detail that should be fixed (I can do that before merging the PR if you don't have time), otherwise all good.

Thank you!

Comment thread netsim/ansible/templates/initial/openbsd-ifconfig.j2
{% else %}
ifconfig {{ intf.ifname }} up
{% endif %}
{% if 'ipv6' in intf and intf.tunnel.mode|default('') in ['wireguard'] %}

@ipspace ipspace Aug 9, 2026

Copy link
Copy Markdown
Owner

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

I think this should go into openbsd.initial.j2. Also, you can use node ID ({{ id }}), it's guaranteed to be unique, so it all comes down to 'fe80::%x/64'|format(id)

@snuffy22 snuffy22 Aug 9, 2026

Copy link
Copy Markdown
Contributor Author

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Are you saying it should go into the wireguard/openbsd.initial.j2 ?
It can't go there, because we kill any IPv4 / IPv6 addresses at the start of the ifconfig macro
That was where I did have it until I realised that it got overridden, aka why it now lives at bottom of the macro.

@ipspace

ipspace commented Aug 9, 2026

Copy link
Copy Markdown
Owner

This is more open for comment than ready for commit.

I'd say it's almost there.

  1. OpenBSD does not create IPv6 LLA addresses on WG interfaces because they are technically multipoint

LAN interfaces are technically multipoint but have LLAs. I'm sure there's some convoluted reason for that decision, but it's not "because the interface is multipoint"

  1. Wireguard IPv6 test does not set prefix length for loopback (so fails for OpenBSD which only does /128)

Thank you, fixed that bit of the integration test.

  1. Wireguard module does not support selecting only IPv4 or IPv6

Talk with @jbemmel ;)

One other question, is there a reason why we might do tunnel setup after our routing protocols like OSPF? If tunnels happened before OSPF, I could move my 'non ideal' hack out of initial and just into the Wireguard config for OpenBSD.

Call it organic growth ;)) Tunnels are implemented as plugins (because there are so many different options, and I expect each option to be well-supported by just a few devices), so they use custom configuration templates, which are executed last 🤷🏻‍♂️

ipspace added a commit that referenced this pull request Aug 9, 2026
@ipspace
OpenBSD tunnel tests for #3750
23b7ed1
@ipspace
ipspace marked this pull request as ready for review August 9, 2026 10:19
@ipspace
ipspace merged commit 5257438 into ipspace:dev Aug 9, 2026
4 checks passed
@jbemmel

jbemmel commented Aug 9, 2026

Copy link
Copy Markdown
Collaborator

5. Wireguard module does not support selecting only IPv4 or IPv6

Talk with @jbemmel ;)

My thinking was that users typically select ipv4 and/or ipv6 at the topology level, rather than the individual modules. Similar to how OSPFv3 isn’t selected directly

But everything can be changed of course - I wanted to get something out there, and then iterate

@snuffy22

snuffy22 commented Aug 9, 2026

Copy link
Copy Markdown
Contributor Author

@jbemmel no issue, just something I noticed vs the GRE module.

@ipspace one other minor note in relation to testing is, we have IPv4/IPv6 flowing over the tunnel but the endpoints themselves are both IPv4. Maybe a third FRR router WG link could be AF IPv6 endpoint to verify that part as well, this way it should be able to make use of the adjust_test functionality I have seen you use in other parts recently (if they didn't support the IPv6 varient).

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment

Reviewers

@ipspace ipspace ipspace approved these changes

Assignees

No one assigned

Labels

None yet

Projects

None yet

Milestone

No milestone

Development

Successfully merging this pull request may close these issues.

3 participants

@snuffy22 @ipspace @jbemmel